Some reading here: https://svelte-5-preview.vercel.app/docs/breaking-changes

(just passing by)

Well that's pretty clear: https://svelte-omnisite.vercel.app/docs/svelte/v5-migration-guide

I'm starting to investigate what's missing to make Svelte 5 happy here, just personal notes:

• svelte 4.x sf console importmap:require [email protected] svelte/[email protected] svelte/internal/[email protected] && pnpm add -D [email protected] && pnpm run build-svelte
• svelte 5.x sf console importmap:require svelte svelte/internal/client svelte/internal/disclose-version && pnpm add -D svelte && pnpm run [email protected]
• svelte version and packages in importmap definition will need to be updated

I'm starting to investigate what's missing to make Svelte 5 happy here, just personal notes:

• svelte 4.x sf console importmap:require [email protected] svelte/[email protected] svelte/internal/[email protected] && pnpm add -D [email protected] && pnpm run build-svelte
• svelte 5.x sf console importmap:require svelte svelte/internal/client svelte/internal/disclose-version && pnpm add -D svelte && pnpm run [email protected]
• svelte version and packages in importmap definition will need to be updated

Small tips: you can get rid of the svelte/internal/disclose-version dependency if you compile the Svelte components with the discloseVersion: false option - documentation

Ok I think I'm on something. I believe that's because the context between svelte and svelte/internal/client is not shared.

In one of the module, init_operations() is called and first_child_getter and next_sibling_getter are defined.
But, on the other module, which depends of first_child_getter and next_sibling_getter, calls to get_first_child (called by mount) fails because first_child_getter is undefined.

I believe this is related to no-build scenarios, like we do with AssetMapper/importmap.

I will investigate more and try to find a solution.

I believe this is related to no-build scenarios, like we do with AssetMapper/importmap.

I will investigate more and try to find a solution.

It is, and some people are trying weird stuff with chunks (i'm not sure to even understand what i'm saying here haha)

To be honest, due to how files are bundled on JSDelivr and how Svelte 5 works, I don't know if we can have Svelte 5 support for AssetMapper... :/

I'd be ok if the support was only for webpack :| But no BC break for AssetMapper please :)

But i don't get how this work as... in the end... there are only compiled assets in a directory right ?

But i don't get how this work as... in the end... there are only compiled assets in a directory right ?

Not with AssetMapper / CDN stuff.

When you compile this .svelte file for Svelte 5:

<script>
    export let name = "Svelte";
</script>

<div>Hello {name}</div>

It become:

import * as $ from "svelte/internal/client";

var root = $.template(`<div> </div>`);

export default function _unknown_($$anchor, $$props) {
	let name = $.prop($$props, "name", 8, "Svelte");
	var div = root();
	var text = $.child(div);

	$.reset(div);
	$.template_effect(() => $.set_text(text, `Hello ${name() ?? ""}`));
	$.append($$anchor, div);
}

Here, we have a dependency to svelte/internal/client, you can install it through importmap:require.

In the render_controller.ts file, we have a dependency to svelte to import mount and unmount functions (if they exists, in Svelte 5). You can also install svelte through importmap:require.

The thing is, that both dependencies svelte and svelte/internal/client contain both the same inlined (and that's the problem) logic (the function init_operations() instead of relying on a common module.

One dependency defines first_child_getter and next_sibling_getter function, and the other dependency tries to use those functions but without success, since the context is not shared across the two dependencies... :/

IMO, the best we can do is to:

1. keep render_controller.js as-if, only support Svelte 3/4
2. and either:
   1. since we can do BC breaks here, create a new UX package symfony/ux-svelte-5, without AssetMapper support, with good devDependencies versions, that's the easier and cleanest solution
   2. or a more and more complex solution with some drawbacks :
      1. add a new option svelte.comptability_version (default to 4),
      2. create a new Stimulus controller for Svelte 5,
      3. try to see how can we warn the user that nothing will work if you use the AssetMapper with svelte.comptability_version = 5, but I don't know how we can do that properly
      4. but, the importmap.php and package.json dependencies will be invalid because by default they contains deps for Svelte 3/4 :/

I'm more in favor of a new dedicated symfony/ux-svelte-5 package, as it will be more easier for us to work on, and more easier for users to use it.

The potential issue I see with creating a new ux-svelte-5 package now is that if Svelte fixes the CDN issue in a future release, we'll have to do a BC break to remove the new package and come back to the initial one

There is not much code in the package, i'm sure we can make something in it to load or or the other file :)

There is not much code in the package, i'm sure we can make something in it to load or or the other file :)

Yeah, but for the moment Svelte 5 only works with Webpack, not with AssetMapper. Even if we can do something "to load or not the other file", it still won't work :s or am I missing something?

Yeah, but for the moment Svelte 5 only works with Webpack, not with AssetMapper.

That's what i reacted on when i said "i'd be ok to no have AssetMapper support"

We can announce a compatibility for only Webpack no ?

Yes we can